1. Field of the Invention
The present invention relates to an apparatus for testing over a multiprocessor bus and more specifically relates to an apparatus for issuing, in response to a selected trigger, a bus request and bus busy signal to freeze operation of a multiprocessor bus until a bus test reset is initiated releasing a bus busy signal and resuming operation of the multiprocessor bus.
2. Description of Related Art
A multiprocessor bus allows a plurality of microprocessors to communicate with one another over the bus. A requesting microprocessor which desires to communicate on the multiprocessor bus issues a bus request to initiate communication. The bus request is received by the controlling microprocessor and surrenders control of the multiprocessor bus to the microprocessor issuing the bus request. A bus grant signal is then sent from the bus to the requesting microprocessor issuing the bus request and the requesting microprocessor begins controlling the bus while sending a bus busy signal to the bus.
Many different multiprocessor buses have been commercially in use. For example, the VME bus by Motorola, the NuBUS by Apple, the MULTIBUS I and II by Intel, the VAXBI bus by Digital Equipment, and also the Q-BUS, the FASTBUS and the FUTUREBUS. Systems using each of these multiprocessor buses have a need for debugging bus operation.
When trouble shooting a slave board on Motorola's VME bus, there comes a time when a user needs to pause controller program execution under certain conditions and take control of the VME bus to write or read data and then step or continue through the rest of the program. A software debugger, such as the RT scope from Ready Systems, located in Palo Alto, California, can be used. Using such a software debugger, the following steps are commonly performed: 1) create a program using a high level language; 2) convert the high level language code into the VME system controller board's microprocessor assembly code using a cross compiler; 3) convert the assembly code to binary code and download into the random access memory of the system processor board; 4) display assembly code on a terminal using the software debugger (assuming the debugger is in the system processor board programmable read only memory or random access memory); and 5) determine where the assembly code corresponds to a line in the high level language code. These software debugging steps are difficult because the user has to be familiar with the assembly language code for the microprocessor of the controller to use the software debugger. Learning the assembly language code of a microprocessor can take considerable time.